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SYSTEMS AND METHODS FOR USING A WEB PORTAL 
TO INTEGRATE INTO A CARRIER RETURN SYSTEM 

FIELD OF THE INVENTION 
10 [0001] The present invention relates generally to systems and methods that 
facilitate the integration between a merchant and a carrier return system. 

BACKGROUND OF THE INVENTION 
[0002] The increased popularity of the World Wide Web has led to an explosion 

15 in catalog and online shopping. The growth in e-commerce reflects in part increased 
purchases from veteran online shoppers, deeper Internet penetration across the 
country and the increased number of familiar bricks-and-mortar retailers online. 
[0003] Some of the benefits to purchasing products online include the ability to 
avoid crowds, perform quick price comparisons across multiple sellers, and access a 

20 wider selection of products. However, there are drawbacks to purchasing goods 
through a retailer web site. One drawback is the inability to inspect an item before 
making the purchase. A consumer that buys a product offline at a traditional retail 
store usually has the opportunity to inspect the color, size and quality of 
workmanship of a good before the purchase is made. In contrast, when a consumer 

25 shops online their decision to purchase is based largely on a written description of 
the product and/or a photograph of the item. No opportunity to inspect the product 
occurs until after the product is purchased and shipped to the consumer. As a result, 
many products that are purchased online are returned. 

[0004] The typical return transaction involves a customer contacting a merchant, 
30 via email or phone, to inform the merchant that the customer intends to return an 
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item previously purchased from the merchant. After approving the return, the 
merchant obtains a return shipping label from a commercial carrier, such as the 
United Parcel Service (UPS), and mails the return shipping label to the customer, 
along with any special instructions on how to package the item to be returned. Next, 
5 the customer repackages the item, affixes the return shipping label to the package 
and drops the package off with the shipper, who delivers it to the merchant. 
[0005] This return process is both time consuming and highly manual. It usually 
takes a week or more for the merchant to obtain a return shipping label from a carrier 
and have the label mailed to the consumer. In addition, the merchant must have 
10 customer service representatives available to receive and approve the customer 
return request, and to initiate the request to the carrier to have a return shipping label 
generated. Further, if the label is lost or destroyed in the mailing process, additional 
delays and expense can result as the consumer contacts the merchant and re-initiates 
the returns process. 

15 [0006] An alternative returns process is sometimes used to avoid some of the 
delays discussed above. In the alternative returns process, the merchant has a return 
shipping label generated for every product sold and encloses the label with the 
product when it is sent to the customer. The benefit of the alternative return process 
is that a customer that wishes to return an item no longer needs to contact the 

20 merchant and already has the label required to return the good. While this eliminates 
many of the delays inherent in the traditional returns process, the merchant is at a 
disadvantage. By including a return shipping label when the product is sent to the 
customer, the merchant essentially abrogates the right to refuse a return. And 
because the merchant is not notified when a customer decides to return an item, the 

25 merchant has no idea as to which or how many items are going to be returned, which 
can lead to inventory management problems. In addition, if the shipping label sent 
to the consumer is missing, lost or destroyed, the delays associated with providing a 
replacement shipping label return. 

[0007] A hurdle in building any effort to streamline the traditional returns 



018360/260051 



process is the need for interaction between the consumer, the merchant and the 
carrier that assumes responsibility for delivery of the returned good. Consumers 
routinely interact with merchants through websites that are setup and controlled by 
the merchant. But the interaction that must occur in an a streamlined returns system 
5 between the carrier and the merchant is anything but routine. Merchants typically 
must integrate their internal systems with those of its carrier to take advantage of the 
carrier's return systems. This can require a great deal of programming and testing, 
which is often time-consuming and expensive. 

[0008] A need therefore exists in the industry for a streamlined return system 
10 that allows a merchant to access and use a carrier return system. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0009] Having thus described the invention in general terms, reference will now 
be made to the accompanying drawings, which are not necessarily drawn to scale, 
15 and wherein: 

[0010] Fig. 1 is a high-level block diagram of an electronic return system in 
accordance with an embodiment of the present invention. 

[0011] Fig. 2 is a high-level process flow diagram that shows several 
embodiments of the present invention. 
20 [0012] Fig. 3 is a high-level block diagram that illustrates the operation of an 
electronic return system in accordance with a first embodiment of the present 
invention. 

[0013] Figs. 4A-4F are illustrative screen shots of web pages that a customer 
uses to navigate a merchant return system in accordance with an embodiment of the 
25 present invention. 

[0014] Figs. 5A-5B show a record layout of a return service request in 
accordance with an embodiment of the present invention. 

[0015] Fig. 6 illustrates a return shipping label and label instruction area in 
accordance with an embodiment of the present invention. 
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[0016] Fig. 7 shows a record layout of a return service response in accordance 
with an embodiment of the present invention. 

[0017] Figs. 8A-8B illustrate an electronic return notification in accordance with 
an embodiment of the present invention. 

[0018] Fig. 9 is a high-level block diagram that illustrates the operation of an 
electronic return system in accordance with a second embodiment of the present 
invention. 

[0019] Fig. 10 is a high-level block diagram that illustrates the operation of an 
electronic return system in accordance with a third embodiment of the present 
invention. 

[0020] Fig. 1 1 is a process flow diagram that illustrates a method of handling 
undeliverable emails in accordance with an embodiment of the present invention. 

SUMMARY OF THE INVENTION 
15 [0021] The present invention is directed to an interface for a return system that 
allows one or more merchants to funnel their returns processing to a central returns 
processing system. A merchant may apply its own, possibly unique set of business 
rules to a customer return request before linking to the interface or, alternatively, the 
interface may be programmed to apply the respective business rules of the various 
20 merchants. In a preferred embodiment, the returns interface maintains the look and 
feel for each of the various merchant so that the integration between the merchant 
system and central returns system is transparent to customers. 

[0022] In one embodiment of the present invention a method of interfacing 
between a first and a second computer system is disclosed to process a request by a 
25 customer to return a good purchased from a merchant. The disclosed method 
includes the steps of establishing an interface system that is capable of 
communicating with the first and second computer systems; receiving at the interface 
system a customer return request from the first computer system; applying one or 
more business rules to the customer return request to determine whether the request 
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is authorized; assembling a return service request based at least in part on the 
customer return request; transmitting the return service request to the second 
computer system; receiving at the interface system an image of a shipping label from 
the second computer system in response to the customer return request; and 
5 providing the shipping label image to the first computer system. 

[0023] In another embodiment of the present invention a method of interfacing 
between a first computer system associated with a merchant and a second computer 
system associated with a commercial carrier is disclosed to process a request by a 
customer to return a good purchased from a merchant. The disclosed method 

10 includes the steps of establishing an interface system that is capable of 
communicating with the first and second computer systems via a computer network 
such as the Internet; receiving at the interface system a customer return request from 
the first computer system; applying one or more business rules to the customer return 
request to determine whether the request is authorized; assembling a return service 

15 request based at least in part on the customer return request; transmitting the return 
service request to the second computer system; receiving at the interface system an 
image of a shipping label from the second computer system in response to the 
customer return request; and providing the shipping label image to the first computer 
system. 

20 [0024] In another embodiment of the present invention a method of interfacing 
between a first computer system associated with a merchant and a second computer 
system associated with a commercial carrier is disclosed to process a request by a 
customer to return a good purchased from a merchant. The disclosed method 
includes the steps of establishing an interface system that is capable of 

25 communicating with the first and second computer systems via a computer network 
such as the Internet; receiving at the interface system a customer return request from 
the first computer system; applying one or more business rules to the customer return 
request to determine whether the request is authorized and to establish a destination 
address for the good to be returned; assembling a return service request based at least 
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in part on the customer return request; transmitting the return service request to the 
second computer system; receiving at the interface system an image of a shipping 
label from the second computer system in response to the customer return request; 
and providing the shipping label image to the first computer system. 
5 [0025] In another embodiment of the present invention a method of interfacing 
between a first computer system associated with a merchant and a second computer 
system associated with a commercial carrier is disclosed to process a request by a 
customer to return a good purchased from a merchant. The disclosed method 
includes the steps of establishing an interface system that is capable of 

10 communicating with the first and second computer systems via a computer network 
such as the Internet; receiving at the interface system a customer return request from 
the first computer system; applying one or more business rules to the customer return 
request to determine whether the request is authorized and to establish a destination 
address for the good to be returned; assembling a return service request based at least 

15 in part on the customer return request; transmitting the return service request to the 
second computer system; receiving at the interface system an image of a shipping 
label from the second computer system in response to the customer return request; 
and providing the shipping label image to the first computer system and to the 
customer. 

20 [0026] In another embodiment, a method of interfacing between a first and a 
second computer system is disclosed to process a request by a customer to return a 
good purchased from a merchant. The disclosed method includes the steps of 
establishing an interface system that is capable of communicating with the first and 
second computer systems; receiving at the interface system, returns data relating to a 

25 customer return transaction; assembling a return service request based at least in part 
on the returns data; transmitting the return service request to the second computer; 
receiving at the interface system, an image of a shipping label from the second 
computer system in response to the return service request; and providing 
electronically the shipping label image to the first computer. 
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[0027] In another embodiment, a method of interfacing between a first and a 
second computer system is disclosed to process a request by a customer to return a 
good purchased from a merchant. The disclosed method includes the steps of 
establishing an interface system that is capable of communicating with the first and 
5 second computer systems; receiving at the interface system, returns data relating to a 
customer return transaction; assembling a return service request based at least in part 
on the returns data; transmitting, via an XML feed, the return service request to the 
second computer; receiving at the interface system, an image of a shipping label 
from the second computer system in response to the return service request; updating 
10 a returns transaction database; and providing electronically the shipping label image 
to the first computer. 

[0028] In another embodiment, a method of interfacing between a first and a 
second computer system is disclosed to process a request by a customer to return a 
good purchased from a merchant. The disclosed method includes the steps of 

15 establishing an interface system that is capable of communicating with the first and 
second computer systems; receiving at the interface system, returns data relating to a 
customer return transaction; assembling a return service request based at least in part 
on the returns data; transmitting, via an XML feed, the return service request to the 
second computer; receiving at the interface system, an image of a shipping label 

20 from the second computer system in response to the return service request; updating 
a returns transaction database with a package tracking number that is disposed on the 
shipping label image; and providing electronically the shipping label image to the 
first computer. 

[0029] In still another embodiment of the present invention, a method of 
25 interfacing between a plurality of merchant computer systems and at least one carrier 
computer system is disclosed to process customer requests to return goods purchased 
from one of said plurality of merchants. The disclosed method includes the steps of 
establishing an interface system that is capable of communicating with the plurality 
of merchant computer systems and the at least one carrier computer system; 
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receiving, at the interface system, a customer return request sent by one of the 
plurality of merchant computer systems; the customer return request including a 
merchant identifier; querying a merchant database with at least the merchant 
identifier to obtain one or more business rules associated with the customer return 
5 request; applying the one or more business rules to the customer return request to 
determine whether to process the request and to associate a return destination address 
with the request; assembling a return service request based at least in part on the 
return request; transmitting the return service request to the at least one carrier 
computer system; receiving, at the interface system, an image of a shipping label 
10 from the at least one carrier computer system; and providing the shipping label 
image to the merchant system from which the request was received. 

DETAILED DESCRIPTION OF THE INVENTION 
[0030] The present invention now will be described more fully hereinafter with 

15 reference to the accompanying drawings, in which preferred embodiments of the 
invention are shown. This invention may, however, be embodied in many different 
forms and should not be construed as limited to the embodiments set forth herein; 
rather, these embodiments are provided so that this disclosure will be thorough and 
complete, and will fully convey the scope of the invention to those skilled in the art. 

20 Like numbers refer to like elements throughout. 

[0031] Many modifications and other embodiments of the invention will come to 
mind to one skilled in the art to which this invention pertains having the benefit of 
the teachings presented in the foregoing descriptions and the associated drawings. 
Therefore, it is to be understood that the invention is not to be limited to the specific 

25 embodiments disclosed and that modifications and other embodiments are intended 
to be included within the scope of the appended claims. Although specific terms are 
employed herein, they are used in a generic and descriptive sense only and not for 
purposes of limitation. 
[0032] A. Architecture 
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[0033] Fig. 1 is a high-level diagram of an electronic return system 10 for 
practicing various aspects of an embodiment of the present invention. In this 
embodiment, the present invention includes a merchant server 110, a customer 120, a 
vendor server 130 and a carrier server 140, each in communication using a common 
5 computer network 100. As used herein, the term customer 120 includes, without 
limitation, an individual or an entity, with or without a personal computer. In the 
disclosed embodiment, the common computer network 100 is the Internet. But it 
will be readily apparent to one of ordinary skill in the art that the present invention 
may be implemented in any networked environment. Moreover, and as disclosed in 
10 more detail below, some of the communications described herein may occur by 
means other than the common computer network 100. 

[0034] As described herein, the customer 120 is the buyer of a good that wishes 
to return it. In a preferred embodiment, the merchant 110 is the entity that sold the 
good to the customer 120 and the vendor 130 is the entity that receives the good that 

15 is being returned. In some cases, of course, a merchant may require that goods be 
returned directly to the merchant, in which case a vendor may not be involved in the 
returns process. Although the present invention is broad enough to include this 
situation, in the disclosed embodiment it will be assumed that a merchant and a 
vendor are involved in the returns process. Finally, other electronic returns models 

20 can, of course, exist that make use of the present invention and these are intended to 
be encompassed by the following disclosure as well. 

[0035] In a preferred embodiment, the merchant 110, vendor 130 and carrier 140 
servers are capable of transmitting and receiving data over the network 100 using 
standard Internet protocols, including HTTP and HTTPS. Similarly, the customer 
25 120 has a computer that can send and receive electronic mail and that is equipped 
with a web browser capable of viewing web pages. As explained below, however, 
the present invention can be implemented even if one or more of these entities are 
not connected to the network 100. As a non-limiting example, the electronic return 
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system described herein will work if a customer 120 uses a phone rather than a 
computer to contact a merchant to request a return. 

[0036] In addition, the present invention may apply to the situation in which a 
customer buys a good from a physical location, such as a merchant retail store and 
5 later decides to return the good. Rather than returning to the physical location of the 
merchant, the customer may elect to use the present invention to initiate the return. 
[0037] Also in a preferred embodiment, an online return application 150 and a 
label generation application 160 reside on the carrier server 140, and a merchant 
return application 115 resides on the merchant server 110. It will be readily apparent 

10 to one of ordinary skill in the art that one or more of these applications can reside 
elsewhere. For example, a label generation application may reside on a separate 
server operated by the carrier or might exist as a carrier component on the merchant 
server 110. The operations of the various applications are described in detail below 
and the present invention is broad enough and intended to encompass embodiments 

15 in which the applications reside on these or other computers. 
[0038] B. Operation 

[0039] In accordance with the present invention, several embodiments of a 
system are herein described that will process a customer's request to return a good 
purchased from a merchant. Fig. 2 is a high-level process flow diagram that 

20 illustrates several of these embodiments. 

[0040] In each of the herein-described systems, a customer contacts a merchant 
and requests the return of a good. Upon approval of the return request, the merchant 
contacts an online return application 150 and provides the shipping information 
necessary to generate a return shipping label. In each of the described embodiments, 

25 the ship from information is address information associated with the customer. The 
merchant may have the ship from information on file or may prompt the customer to 
enter and/or modify the ship from information as part of the return transaction. The 
destination or consignee information of the shipping label may be a merchant 
address or a vendor address, depending on where the product is to be returned. 

-10- 
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[0041] In the first process flow shown in Fig. 2, the carrier generates a label in 
Step 1 and returns the label to the merchant in Step 2. As described in greater detail 
below, the shipping label that is generated and transmitted to the merchant may be 
formatted via Graphics Interchange Format (GIF), Eltron Programming Language 
5 (EPL2), portable document format (PDF) or via other formats known in the art. The 
merchant then has the option of presenting the label image to the customer's browser 
(Step 3) or to store the label on the merchant server and provide the customer with a 
hyper-text link to the label via email (Steps 4 and 5). 

[0042] Another embodiment of the present invention is illustrated by the second 

10 process flow of Fig. 2. In this process flow, instead of transmitting a label image, the 
carrier generates a label delivery link to the carrier server. In this embodiment, the 
information necessary to generate a shipping label is embedded in the link. When 
the label delivery link is activated, either by the merchant or customer, a call is made 
to the label generation servlet and a shipping label is dynamically generated and 

1 5 delivered to the customer browser. 

[0043] In Step 10, the carrier generates a label delivery link in response to a 
return request. If the merchant decides to have the label delivery link sent directly to 
the customer, the process proceeds to Step 11 and the carrier sends an email 
containing the label link to the customer. In Step 12, the customer activates the label 

20 delivery link, which causes a shipping label to be generated and delivered to the 
customer's browser. Alternatively, the merchant can have the process proceed to 
Step 13 where the label delivery link is sent to the merchant. At that point, the 
merchant can either activate the label link and have the shipping label delivered to 
the customer browser (Step 14), or the merchant can forward the label delivery link 

25 to the customer via email and permit the customer to activate the link (Steps 15 and 
16). 

[0044] In the final process flow shown in Fig. 2, the online return application 
150 determines the carrier site closest to the customer and prints the generated 
shipping label at the local carrier site (Step 20). The process then can proceed to 
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Step 21 wherein a carrier driver takes the label to the customer, affixes the label to 
the package and accepts the package. Alternatively, the carrier will mail the label to 
the customer and have the customer assume responsibility for affixing the label and 
delivering the labeled package to a carrier drop off location. 
5 [0045] The following paragraphs describe in greater detail the various 
embodiments summarized above. 

[0046] Fig. 3 is a high-level diagram that illustrates a first method by which an 
online return application 150 processes a return request from a customer 120. The 
process starts in Step 200 with a customer 120 contacting a merchant and notifying 

10 the merchant that the customer wishes to return a good that the customer previously 
purchased. The following paragraphs describe a situation in which a customer 120 
contacts the merchant through a merchant website. But it will be readily apparent 
that a customer 120 might request a return over the telephone through a customer 
service representative or by phoning the merchant directly. These and other methods 

15 by which a customer 120 might submit a return request are encompassed by this 
invention. 

[0047] Figs. 4A-4F illustrate the type of web pages that a merchant might use to 
permit a user to submit a return request. The term user is used rather than customer 
to expressly include the situation in which a customer 120 communicates with a 
20 customer service representative that uses a merchant website to enter the customer's 
return request. 

[0048] Fig. 4A shows a merchant web page that lists the prior orders 200 that a 
customer 120 has placed with the merchant along with the order date 205, total 210 
and status 215 associated with each order 200. For each order 200, the customer 120 
25 is given the option of clicking on a hyperlink labeled "Track" 220 to track an order 
shipment or "Return" 225 to initiate the process of requesting a return. Additional 
options on the web page of Fig. 4A include links to change billing 230 and shipping 
address 235 information. 
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[0049] In this example, if the customer 120 clicks the return link 225 
corresponding to order number 815499 the merchant server 110 links to a web page 
such as that shown in Fig. 4B. This web page lists the goods that comprise order 
815499 and includes a stockkeeping unit (SKU) number 250, a good description 255, 
5 the quantity 260 of a particular good purchased in the order and a price 265 paid for 
the good. There are two goods listed in Fig. 3B: a 56K V90 KFLEX Dual Mode PCI 
D/F/V Modem Motorola Chip ("Motorola chip") and a SOX Reader EIDE 650A 
128k 85ms 6000 kb/sec Vert Mnt Capb ("50x reader"). In this example, a return 
merchandise authorization (RMA) #319910 has already been issued for the Motorola 

10 chip. This may be because the customer 120 previously submitted a return request 
for the Motorola chip or that the merchant has a policy to automatically grant return 
requests associated with the chip. As to the 50x reader, the customer 120 is given 
the option of checking a check box 270 to request a return of that item. 
[0050] After checking the check box 270 associated with the 5 Ox reader and 

15 clicking on the Returned Check Item(s) box 275, the customer 120 proceeds to Fig. 
4C. With reference to Figs. 4C - 4E, the customer 120 is next prompted for 
information about the good being returned. This information may for example aid 
the merchant in determining whether to authorize the return and/or to determine 
whether the good should be returned to the merchant or to the vendor that supplied 

20 the good. In this example, the customer 120 is prompted to supply the reason for the 
return 280 (Fig. 4C), whether the package has been opened 285 (Fig. 4D) and 
whether the customer 120 seeks a credit or a replacement 290 (Fig. 4E). These steps 
are presented for illustrative purposes only and it should be readily apparent that 
different merchants will use different criteria to determine whether a good may be 

25 returned and under what conditions. Moreover, a merchant may use an automatic 
returns process like the one described herein or may alternatively review each return 
on an individual basis. 

[0051] Upon entering the requested information, the customer 120 clicks the 
Request an RMA# button 295 and the process proceeds to Fig. 4F. In this example, 
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the merchant has authorized the return and assigned a RMA number of 323530 to the 
5 Ox reader. In an alternative embodiment, the merchant does not authorize returns 
immediately and the customer 120 receives a web page with a message indicating 
that the return request will be processed. Once the merchant approves the return 
5 request and assigns a RMA number to the transaction, a shipping label link 300 is 
sent to the customer 120. In one embodiment, the merchant presents a shipping label 
in the customer browser. In a preferred embodiment, the merchant emails a label 
delivery link 300 to the customer 120 and the customer 120 presents the shipping 
label to the customer browser by activating the link. Additional embodiments and 

10 methods of presenting a shipping label to a customer are intended to be encompassed 
by the present invention, some of which are discussed more fully herein. 
[0052] When the customer 120 clicks on the label delivery link 300, the 
customer's return request is sent from the merchant website to a merchant return 
application 115. In a preferred embodiment, the merchant return application 115 

15 resides on the same server as the merchant website. But it will be readily apparent to 
one of ordinary skill in the art that a merchant return application may reside on a 
separate server or on a stand-alone device. The merchant return application 115 
confirms that the customer 120 has provided the necessary returns information, 
validates the data provided and generates a return service request 305. The return 

20 service request 305 is then sent to the merchant server 110 where it is forwarded to 
the carrier server 140 via the common computer network 100. 
[0053] In a preferred embodiment, the return service request 305 is formatted as 
an Extensible Markup Language (XML) file. XML is well known to one of ordinary 
skill in the art as an open standard for defining markup languages to represent 

25 structured information over the Internet. In general, XML describes a class of data 
objects called XML documents and partially describes the behavior of computer 
programs that process them. The use of XML in connection with the present 
invention is for illustrative purposes only and it will be readily apparent to one of 
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ordinary skill in the art that the present invention may be implemented using other 
data formats. 

[0054] Figs. 5A and 5B show a typical XML return service request 305. In this 
non-limiting example, a return service request 305 includes access request 
5 information such as the merchant's access license number 310, userid 315 and 
password 320, label specification information 322 such as a print method 325, stock 
size 330, HTTP user agent 332, and image format 335, shipment information 337 
such as shipper 340 (the merchant), destination or ship to 345 (the vendor) and 
origination or ship from 350 (the customer 120) data, return service 351, service 352, 

10 payment information 355 and package information 360. In a preferred embodiment, 
the package information 360 includes a vendor email address 365 and an 
undeliverable email address 370, both of which are discussed in greater detail below. 
[0055] Returning to the embodiment of Fig. 3, in Step 210 the online return 
application 150 receives the return service request 305 created by the merchant 

15 return application 115 and transmitted by the merchant server 110. In a preferred 
embodiment, the online return application 115 resides on the carrier server 140. But 
it will be readily apparent to one of ordinary skill in the art that the online return 
application 115 may reside on a separate server or on a stand-alone device. Upon 
receipt, the online return application 150 verifies that the validity of the data stored 

20 in the return service request 305 and assigns a package tracking number 375 to the 
return transaction. In a preferred embodiment, when a package tracking number 375 
is assigned, the shipping information related to the return transaction is stored in a 
package tracking database 380. Later, when the package is shipped, the parties to the 
transaction can track the progress of the package through the carrier system using the 

25 package tracking number 375. In a preferred embodiment, the online return 
application 150 does not itself assign a package tracking number 375, but 
communicates with another carrier application that assigns package tracking 
numbers 375 and tracks packages shipped within the carrier system. 
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[0056] In Step 215, the online return application 150 forwards the return service 
request 305 to a label generation application 160. In a preferred embodiment, the 
online return application 150 sends the label generation application 160 only the 
shipping and label information that is required to generate a package label. The 
5 online return application 150 thus includes the additional functionality of extracting 
the shipping and label information from the return service request 305 and 
reformatting the information into a file that is inputted into the label generation 
application 160. The label generation application 160 may reside on the same server 
as the online return application 150 or may reside on another server or on a stand- 
10 alone device. 

[0057] In Step 220, the label generation application 160 generates a return 
shipping label 400 from the shipping and label information, and transmits the return 
shipping label 400 back to the online return application 150. The process of 
generating a return shipping label 400 is well known to one of ordinary skill in the 

15 art and therefore, is not described in detail herein. 

[0058] Fig. 6 illustrates a return shipping label 400 in accordance with an 
embodiment of the present invention. In this embodiment, the return shipping label 
400 consists of two portions: a label area 405 and a text area 410. The label area 405 
includes an origination shipping address 415, a destination shipping address 420, 

20 Maxicode™ 425, carrier service level 427, package weight 430, post office code 
435, post office bar code 440, package tracking number 375, carrier bar code 450, 
billing code 455, merchandise description 460, service identification 465, and RMA 
number 470. The text area 410 includes instructions as to how to print and affix the 
label 475, shipping instructions 480, and a drop-off location link 485. In one 

25 embodiment, the drop-off location link 485 is a link that includes the zip code of the 
origination shipping address embedded in the URL address. When the link is 
activated, the user receives a web page that lists the carrier drop-off locations that are 
closest to the origination shipping address. Alternative embodiments of the return 
shipping label 400 are also well-known in the art and are encompassed by the present 
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invention, and may include such additional features as packing instructions, 
advertisements or a link to a merchant or vendor web site. Additional links may be 
added to allow a customer to provide feedback or complaints. 
[0059] Returning to Fig. 3, in Step 225 the online return application 150 
5 transmits the return shipping label 400 to the merchant server 110 accompanied by a 
return service response 500. The return shipping label 400 may be transmitted as a 
GIF, EPL2, or PDF file or via other formats that are well known in the art for 
transmitting an image. In one embodiment, the return service response 500 is 
formatted as XML formatted data, but could readily be formatted using other formats 

10 known in the art. Fig. 7 illustrates a typical XML return service response 500 that a 
merchant might receive in Step 225. In this embodiment, the return service response 
500 includes a response section 505 with fields for transaction reference 510 and 
response status code 515. The transaction reference 510 is a field for caller data. In 
a preferred embodiment, the transaction reference 510 allows the customer to add 

15 information to tie the response to the original return request. The response status 
code 515 notifies the merchant if an error occurred during the processing of the 
XML return service request. The XML return service response 500 also includes a 
shipment results section 520, a billing weight section 525, a shipment identification 
number 530 and a package tracking section 535. In one embodiment, the shipment 

20 identification number 530 is used to support multi-piece package shipments. In 
many cases, the package tracking number 375 will be used as the shipment 
identification number 530. In multi-piece shipments, the shipment identification 
number 530 is the package tracking number 375 of the first package. 
[0060] Returning again to Fig. 3, in Step 230 the merchant provides the return 

25 shipping label 400 to the customer 120. In a preferred embodiment, the foregoing 
process of generating a return service request 305 and generating a return shipping 
label 400 is near instantaneous. Thus, an electronic image of the return shipping 
label 400 is delivered to the customer's browser in response to the customer's 
activation of the shipping link label 300 while the customer is still on the merchant 
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website. Alternatively, the steps of generating and processing a return service 
request 305 may not be instantaneous and the merchant may provide the customer 
120 with an electronic image of a return shipping label 400 at a later time. Delivery 
of the return shipping label 400 from the merchant to the customer 120 can occur via 
5 email, the postal system or by other methods discussed herein. In one embodiment, 
the merchant or the carrier may store the electronic image of the return shipping 
label 400 on one of the merchant server 110 and carrier server 140 and the merchant 
will send an email to the customer 120 that contains a link to the label image. 
Alternatively, a return shipping label 400 may be printed by a carrier and hand- 

10 delivered by a driver to the customer 120. Additional methods of providing an 
electronic image of a return shipping label 400 to a customer 120 exist are known in 
the art and are intended to be encompassed by the present invention. 
[0061] In Step 235, the online return application 150 sends an electronic return 
notification 550 to the vendor server 130 indicating that a return service request 305 

15 has been processed and that a customer 120 intends to ship a returned good to the 
vendor. In a preferred embodiment, an electronic return notification 550 is generated 
for every return service request 305 processed by the online return application 150. 
In an alternative embodiment, an electronic return notification 550 is automatically 
generated whenever the destination shipping address 420 is different from the 

20 merchant's shipping address. In still another embodiment, an electronic return 
notification is generated whenever the merchant includes a vendor email address 365 
in the return service request 305. 

[0062] Figs. 8A and 8B illustrate an electronic return notification 550 in 
accordance with an embodiment of the present invention. In this embodiment, the 
25 electronic return notification 550 consists of two portions: a human-readable area 
555 (Fig. 8A) and a machine-readable area 560 (Fig. 8B). The human-readable area 
555 includes an origination shipping address 415, destination shipping address 420, 
package tracking number 375, merchandise description 460, UPS service level 427, 
package weight 430 and RMA number 470. In this manner, the human-readable area 

-18- 

018360/260051 



555 of the electronic return notification 550 provides returns transaction information 
to vendors that rely on individuals rather than machines to track incoming packages 
and returns. 

[0063] Fig. 8B illustrates the machine-readable area 560 of an electronic return 
5 notification 550 in accordance with an embodiment of the present invention. In this 
embodiment, the machine-readable area 560 is formatted as an XML document, but 
it will be readily apparent to one of ordinary skill in the art that other data formats 
exist and may be used with the present invention. The machine-readable area 560 
also contains the returns transaction information, but allows a vendor with an 

10 automated shipping system to process the electronic return notification 550 without 
requiring a manual review of the email text. In a preferred embodiment, the 
machine-readable area 560 includes shipper information 340, an origination shipping 
address 415, a destination shipping address 420, a merchandise description 460, 
package weight 430, package tracking number 375 and RMA number 470. Also in a 

15 preferred embodiment, the machine-readable area 560 is appended to the human- 
readable area 555 and comprises an electronic mail. But it will be readily apparent 
that either or both sections of the electronic return notification 550 can be transmitted 
separately and by means other than email. Thus, in an illustrative alternate 
embodiment, in Step 235 a vendor might receive a facsimile of just the human- 

20 readable area 555 of the electronic return notification 550. 

[0064] Fig. 9 is a high-level diagram that illustrates a second method by which 
an online return application 150 processes a return request. The process starts in 
Step 700 with a customer 120 contacting a merchant and notifying the merchant that 
the customer wishes to return a good that the customer 120 previously purchased. 

25 This notification may or may not occur electronically but in a preferred embodiment 
occurs via a merchant web site that resides on the merchant server 110. 
[0065] In Step 705, the merchant application 115 processes the return request 
and generates a return service request 305, which is transmitted to the label 
generation application 150. In a preferred embodiment, the return service request 
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305 is formatted as an XML document but other formats are known in the art and 
may be used with the present invention. Upon receipt of the return service request 
305, the online return application 150 verifies the validity of the transmitted data and 
assigns a package tracking number 375 to the return request. In an alternative 
5 embodiment, the online return application 150 does not itself assign a package 
tracking number 375 to the return transaction, but communicates with another carrier 
application that assigns package tracking numbers and tracks packages shipped 
within the carrier system. 

[0066] In Step 710, the online return application 150 forwards the return service 
10 request 305 to a label generation application 160. In an alternative embodiment, the 
online return application 160 extracts the shipping and package label information 
from the return service request 305 and reformats the information before it is sent to 
the label generation application 160. 

[0067] In Step 715, the label generation application 160 generates a return 
15 shipping label 400 from the shipping and package label information, and transmits 
the return shipping label 400 back to the online return application 150. 
[0068] In Step 720, the online return application 150 sends a return service 
confirmation 600 to the merchant server 140. In a preferred embodiment the return 
service confirmation 600 is formatted as an XML document, but it will be readily 
20 apparent to one of ordinary skill in the art that other data formats exist and may be 
used with the present invention. In one embodiment, the information contained in 
the return service confirmation 600 is the same as that in the electronic return 
verification 550 (see Fig. 8b). In alternative embodiments, the return service 
confirmation 600 may include a link to the return shipping label 400 or an encoded 
25 label delivery link 625 (discussed below). 

[0069] In Step 725, the online return application 150 sends an electronic return 
notification 550 to the vendor server 130 indicating that a return service request 305 
has been processed and that a customer 120 intends to ship a returned good to the 
vendor. In a preferred embodiment, the electronic return notification 550 has a 
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machine-readable area 560 appended to the human-readable area 560 to allow 
automatic input into a vendor shipping system without the need for human 
intervention. In alternative embodiments, the returned good is shipped directly to the 
merchant and no electronic return notification 550 is generated, as no vendor is 
5 involved. Alternatively, only the machine-readable area 560 of the electronic return 
notification 550 is supplied to the vendor. 

[0070] In Step 730, the online return application 150 generates and sends a return 
service email 630 to the customer 120. In one embodiment, the return service email 
630 includes a link to an image file of a return service label 400. The return service 

10 email 630 can also include an encoded label delivery link 625. In a preferred 
embodiment, the online return application 150 generates the encoded label delivery 
link 625, which is a hypertext link to a uniform resource locator (URL) with 
additional information appended that identifies the return shipping label 400 
generated for the return service request 305. In a preferred embodiment of the 

15 delivery link 625 includes a link to a URL. But it will be readily apparent that the 
delivery link 625 may include any encoded or encrypted string of characters which 
will cause the online return application or other application in the return services 
system to respond with an image of the desired shipping label. Moreover, the 
shipping label delivered to the customer browser may be returned from a storage 

20 location or generated dynamically at the time of activation of the link 625. 

[0071] In a preferred embodiment, the label delivery link 625 when activated 
links to the URL of a label generation servlet 650. Servlets are well known in the art 
as Java applications that run in a web server or application server and provide server- 
side processing. Because they are written in Java, servlets are portable between 

25 servers and operating systems. The servlet programming interface (Java Servlet API) 
is a standard part of the Java 2 platform, enterprise edition (J2EE). If a Web server, 
such as Microsoft's Internet Information Server (IIS), does not run servlets natively, 
a third-party servlet plug-in can be installed to add the runtime support. 
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[0072] The use of a Java servlet in this embodiment is for illustrative purposes 
only. One of ordinary skill in the art will readily recognize that there are many 
methods of invoking the dynamic generation or recovery of the shipping label. For 
example, the target of the URL could be an application written in C, C++, or any 
5 other computer language invoked through a common gateway interface or via other 
means. 

[0073] In an alternative embodiment, the label delivery link 625 when activated 
links to the URL of the online generation application 150, which establishes the link 
to a label generation servlet 650. 

10 [0074] In a preferred embodiment, the information appended to the URL in the 
label delivery link 625 to identify a return service label 400 includes a package 
tracking number 375, a locality string 635, a merchant registration identification 640 
and, optionally, a return service label creation date 630. Because this information 
identifies a return service label 400 it contains potentially sensitive shipping 

15 information; therefore, in a preferred embodiment, the information is encrypted to 
prevent unauthorized access as the return service email 630 passes through a 
computer network 100 such as the Internet. In the preferred embodiment, the 
information string appended to the label delivery link 625 is encrypted using triple 
data encryption standard (DES) techniques and is encoded. 

20 [0075] In Step 735, the customer 120 receives the return service email 800 and 
activates the label generation servlet 650 by clicking on the label delivery link 625. 
The foregoing steps of processing a return service request 305 may be near 
instantaneous, or there may be a delay between the customer's request to make a 
return and the transmittal of a return service email 800 containing a label delivery 

25 link 625. Upon activation of the label delivery link 625, the information string is 
decoded and decrypted. In one embodiment, the online return application 150 
receives the information string and performs the decoding and decryption processes. 
In an alternative embodiment, the label generation servlet 650 performs the decoding 
and decryption processes. 
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[0076] The online return application 150 extracts the package tracking number 
375 and merchant registration identification 640 from the decrypted and decoded 
information string. This information is then compared against a return label database 
670 to retrieve the shipping information that is necessary to regenerate the requested 
5 return shipping label 400. In one embodiment, a new record is added to the return 
label database 670 every time that a return shipping label 400 is generated. In 
another embodiment, the return label database 670 is populated only when a 
customer 120, merchant or vendor has requested that a return shipping label 400 be 
saved for possible recovery and/or regeneration. In yet another embodiment, the 
10 shipping information stored on the return label database 670 is kept for a finite 
period and is erased or migrated after the expiration of a predetermined period or 
occurrence of a predetermined condition. 

[0077] In Step 740, the online return application 150 generates a return shipping 
label 400 using the shipping information obtained from the return label database 670 

15 and transmits the return shipping label 400 to the customer 120. In one embodiment, 
a copy of the return shipping label 400 associated with the decoded and decrypted 
package tracking number 375 and merchant registration identification 640 is stored 
on the return label database 670. In another embodiment, a copy of the return 
shipping label 400 is not stored on the return label database 670 and the online return 

20 application 150 sends the associated shipping information to the label generation 
application 160 to have the return shipping label 400 generated. 
[0078] In one embodiment, a return shipping label 400 and/or the shipping 
information necessary to regenerate a return shipping label 400 is indexed by the 
package tracking number 375 and merchant registration identification 640. In an 

25 effort to obtain additional security, an alternative embodiment may also require a 
return service label creation date 630 to regenerate a return service label 400. In 
such an embodiment, the return service label creation date 630 may be included in 
the encrypted and encoded information string transmitted to the online return 
application 150 upon activation of the label delivery link 625. 
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[0079] Label recovery is also available in the present invention. Label recovery 
exists to cover the contingency of a customer being unable to print a label In such 
case, the merchant has the ability to transmit a label recovery request to the online 
return application and receive another copy of the return shipping label generated for 
5 the original return service request. For example, upon receipt of a recovery request, 
another copy of the electronic image of a return shipping label may be provided to 
the merchant or, alternatively, the label delivery link associated with the original 
return request may be regenerated and re-transmitted. 

[0080] Fig. 10 is a high-level diagram that illustrates a second method by which 

10 an online return application 150 processes a return request. The process starts in 
Step 800 with a customer 120 contacting a merchant and notifying the merchant that 
the customer wishes to return a good that the customer 120 previously purchased. 
This notification may or may not occur electronically but in a preferred embodiment 
occurs via a merchant web site that resides on the merchant server 110. 

15 [0081] In Step 805, the merchant application 115 processes the return request 
and generates a return service request 305, which is transmitted to the label 
generation application 150. In a preferred embodiment, the return service request 
305 is formatted as an XML document but other formats are known in the art and 
may be used with the present invention. Upon receipt of the return service request 

20 305, the online return application 150 verifies the validity of the transmitted data and 
assigns a package tracking number 375 to the return request. In an alternative 
embodiment, the online return application 150 does not itself assign a package 
tracking number 375 to the return transaction, but communicates with another carrier 
application that assigns package tracking numbers and tracks packages shipped 

25 within the carrier system. 

[0082] In Step 810, the online return application 150 forwards the return service 
request 305 to a label generation application 160. Alternatively, the online return 
application 150 does not send the return service request 305 to the label generation 
application 160 and instead extracts and sends just that shipping and package label 
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information that is required to generate a return shipping label 400. In Step 815, the 
label generation application 160 generates a return shipping label 400 from the 
shipping and package label information, and transmits the return shipping label 400 
back to the online return application 150. 
5 [0083] In Step 820, the online return application 150 sends a return service 
confirmation 600 to the merchant server 140. In a preferred embodiment the return 
service confirmation 700 is formatted as an XML document, but it will be readily 
apparent to one of ordinary skill in the art that other data formats exist and may be 
used with the present invention. Also, in a preferred embodiment, the return service 
10 confirmation 600 includes an image file for the return shipping label 400. In 
alternative embodiments, the return service confirmation 600 includes a link to the 
return shipping label 400 or, if security is a necessary or desired, to an encoded label 
delivery link 625. 

[0084] In Step 825, the online return application 150 sends an electronic return 
15 notification 550 to the vendor server 130 indicating that a return service request 305 
has been processed and that a customer 120 intends to ship a returned good to the 
vendor. In a preferred embodiment, the electronic return notification 550 has a 
machine-readable area 560 appended to the human-readable area 560 to allow 
automatic input into a vendor shipping system without the need for human 
20 intervention. In alternative embodiments, the returned good is shipped directly to the 
merchant and no electronic return notification 550 is generated, as no vendor is 
involved. 

[0085] In Step 830, the online return application 150 accesses a carrier facility 
database 690 using the origination shipping address 415 to determine which local 
25 carrier facility 695 is responsible for deliveries to and from the customer's address. 
The carrier facility database in a preferred embodiment resides on a carrier server 
140, but it will be readily apparent that carrier facility information can be stored on a 
wide variety of computers and/or other electronic devices known in the art. In a 
preferred embodiment, the online return application 150 then transmits an image of 
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the return shipping label 400 to a printer located at the local carrier facility 695 
where the return shipping label 400 is printed. In an alternative embodiment, the 
online return application sends the return shipping label 400 to a computer or server 
at the local carrier facility 695 where an operator prints the return shipping label 400. 
5 [0086] In Step 835, a driver from the local carrier facility 695 picks up the return 
shipping label 400 and takes it to the origination shipping address 415, which in a 
preferred embodiment is the customer's address. The driver then picks up the good 
that is being returned from the customer 120, affixes the return shipping label 400 to 
the package and places it in the carrier shipping system where it is ultimately 

10 delivered to the destination shipping address 420. 

[0087] If the customer 120 is not home when the driver attempts to pick up the 
package, the driver may leave the return shipping label 400 for the customer 120 or 
may attempt to pick up the package at a later date. In a preferred embodiment, the 
carrier service level 427 determines which action a driver takes if the customer 120 

15 is not home for the pick up attempt. In one embodiment, a carrier offers a single 
attempt service in which the driver makes one attempt to pick up the package. In the 
single attempt service, the driver leaves the return shipping label 400 at the 
customer's residence if the customer 120 is not home when the pick up attempt is 
made. The customer 120 thus is required to affix the return shipping label 400 to 

20 the package and place the package in the carrier shipping system by delivering it to a 
carrier drop-off location. In alternative embodiments, other carrier service levels 427 
are available in which the driver will return on multiple occasions to try to pick up 
the package. In the preferred embodiment, a carrier offers single attempt and three 
attempt carrier service levels 427 though other levels of service can be offered in 

25 accordance with the present invention. 

[0088] Another aspect of the present invention is a system and method for 
handling undelivered email. Invalid email addresses are a recurring problem in any 
system that relies upon communication through email and the problems are 
exacerbated in automated systems due to the lack of human involvement. In many 
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cases, an invalid email address is a result of a simple typographical error, but invalid 
addresses can occur from outdated Internet accounts or any of a host of other reasons 
that are well known in the art. 

[0089] In the present invention, communication between the customer 120, 
5 merchant server 110, carrier server 140 and vendor server can occur via email. For 
example, in a preferred embodiment a carrier relies upon the vendor email address 
365 provided by the merchant in the return service request 305 to transmit an 
electronic return notification 550 to the vendor server 130. If the vendor email 
address 365 provided by the merchant is invalid or otherwise undeliverable, there is 
10 a possibility that the vendor server 130 will not receive the electronic return 
notification 550. At a minimum, human intervention by the carrier and/or the 
merchant may be required to address the problem. 

[0090] Fig. 11 is a high-level block diagram of a method of handling 
undeliverable emails in accordance with an embodiment of the present invention. In 

15 Step 900, the online return application 150 receives a return service request 305 from 
a merchant that includes a vendor email address 365. In a preferred embodiment, the 
return service request 305 also includes a bounce email address 370. The bounce 
email address 370 may be the merchant's email address, the vendor's email address 
or a customer service or other email address of a person or persons that are prepared 

20 to handle undelivered emails. 

[0091] In Step 910, the online return application 150 generates and sends an 
electronic return notification 550. In a preferred embodiment, the electronic return 
notification 550 includes an encrypted XML document attached to the email that 
includes the bounce email address 370. In a preferred embodiment, the XML 

25 document is encrypted using triple data encryption standard (DES) techniques, but 
other encryption techniques are well known in the art and can be used with the 
present invention. 

[0092] If the electronic return notification 550 is returned as undeliverable (Step 
920), the online return application 150 retrieves the XML attachment from the 
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undelivered email and forwards the electronic return notification 550 to the bounce 
email address 370. The online return application 150 forwards the undelivered email 
to the merchant server 110 under the assumption that the merchant or other entity 
associated with the bounce email address 370 is equipped to address the issue that 
5 caused the electronic return notification 550 not to be delivered. One of ordinary 
skill in the art will readily recognize that the undelivered email may also be 
forwarded to a customer 120, a merchant return application 115 or to any other 
person or entity that has a valid email address. 
[0093] C. Network Interface to the Electronic Return System 

10 [0094] Another aspect of the present invention is a network interface 700 

between the electronic return system 10 and the customers and merchants that use the 
system. The foregoing description of the electronic return system 10 assumes that the 
merchant 110 and vendor 130 servers are configured to communicate with the carrier 
server 140 and to generate the return service request 305 that is required by the carrier's 

15 online return system 150 to generate a return shipping label 400. But in practice the 
programming effort to interface the merchant and vendor systems with the carrier return 
system 10 can be substantial. An aspect of the present invention is a network interface 
700 (sometimes referred to herein as a returns portal 700) that is configured to handle 
the communications between a carrier's online return system, a merchant and a 

20 customer. 

[0095] Fig. 12 is a block diagram that illustrates an embodiment of how a returns 
portal 700 can serve as an interface for a carrier online return system 150 in an 
electronic return system 10. The process begins at Step 1000 with a customer 120 
contacting a merchant 110 to return a good previously purchased from the merchant 
25 110. In a preferred embodiment, the merchant 110 receives the return request and 
passes the returns information to the returns portal 700 (Step 1010). This link of the 
customer from the merchant website to a returns portal 700 can occur in a variety of 
ways. For example, a merchant may have a "Returns" option on a merchant website 
that automatically forwards a customer to a dedicated returns portal 700 that is 
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established for that merchant. In such case, the returns portal 700 may be designed to 
maintain the look and feel of the merchant website so that the customer 120 associates 
the processing of the returns with the merchant. Alternatively, the customer 120 may 
be linked to a general returns portal 700 that is configured to handle returns for multiple 
5 merchants. In this alternative embodiment, the link used to connect the customer 120 to 
the returns portal 700 may specify the associated merchant or the customer can be 
prompted to enter the name of the merchant as part of the return transaction. 
[0096] In a preferred embodiment, a function of the returns portal 700 is to apply 
the merchant business rules that determine whether the customer is authorized to return 
10 a good. Alternatively, a merchant may elect to use its own internal systems to apply its 
business rules and will link to the returns portal 700 only after a return is approved. In 
this alternative embodiment, the returns portal 700 handles none of the authorization 
processing and serves solely as an interface between the merchant and carrier return 
systems. 

15 [0097] The following paragraphs describes an embodiment in which a returns 
portal 700 is used to apply a merchant's business rules regarding whether to approve or 
deny a customer's request to return a good. The returns portal 700 in the following 
illustration is described as dedicated to a single merchant and therefore is configured to 
handle only those business rules and return requests for a specified merchant. But one 

20 of ordinary skill will readily recognize that the processes described herein have equal 
applicability to general returns portals 700 that are configured to handle the returns 
authorization and processing for multiple merchants, each of which can have specific 
business rules related to returns. Specifically, in the case of a returns portal 700 
configured for multiple merchants, the return request will include a merchant identifier 

25 or some other indicator that indicates which merchant is associated with the return 
request. This merchant identifier will then be used by the returns portal to identify the 
appropriate business rules, and perhaps even the appropriate web pages, to use in 
processing the return transaction. 
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[0098] In Step 1010, the merchant website connects to the returns portal 700 to 
process a customer's request to return a good. In a preferred embodiment, the merchant 
performs some initial processing of the transaction on a merchant website and passes 
some information to the returns portal 700 about the returns transaction. For example, 
5 the merchant may use its own website to capture and/or confirm customer shipping 
information, such as the home address of the customer, and may use product or order 
history information to identify the good that the customer wishes to return. A benefit of 
this process is that customer shipping and product information is transferred 
electronically thereby eliminating the necessity of manual input by the customer and the 

10 inherent potential for key entry errors. In an alternative embodiment, however, little or 
no information about the returns transaction is passed to the returns portal 700 and the 
customer is prompted to manually enter the required information at the portal 700. In 
still another alternative embodiment, little or no information about the specifics of the 
return is passed to the returns portal 700 initially, but the portal is configured and 

1 5 authorized to access the merchant customer and product databases, thereby allowing the 
portal to obtain the information necessary to process the return request. The access 
between the returns portal 700 and the merchant databases may occur remotely via a 
network 100 (such as the Internet) or, in the case of a returns portal dedicated to a single 
merchant, the returns portal 700 may reside on the same server as the merchant 

20 databases. 

[0099] In a preferred embodiment, the merchant has communicated its business 
rules for returns processing and the returns portal 700 applies the merchant's business 
rules to the customer's return request. The variety and types of business rules that a 
merchant might use to approve or deny a return request are too numerous to list. A list 
25 of some of the factors that might be considered in processing a return include, without 
limitation, the date of purchase, the nature of the good, whether the good has been 
opened, the reason for the return and the conditions of purchase. Moreover, the 
business rules of the merchant may determine the disposition of the good to be returned. 
As an example, a merchant may have business rules that require that unopened goods 
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be returned to a first location for restocking, goods that have been opened but are 
otherwise non-defective be returned to a second location for repackaging, defective 
goods be returned to a third facility for repair, and hazardous or consumable products 
be returned to a fourth facility for destruction. One of ordinary skill in the art will 
5 readily recognize that any number of business rules can be established and implemented 
by a returns portal 700 in accordance with the present invention. 
[00100] If the return is authorized by the merchant's business rules, the returns 
portal 700 assembles a XML return service request 305 from the returns data collected 
from the merchant and/or customer and passes the request 305 to the online return 

10 application 150 of the carrier server 140 (Step 1020). Upon receipt, the online return 
application 150 verifies that the validity of the data stored in the return service 
request 305 and assigns a package tracking number 375 to the return transaction. In 
a preferred embodiment, when a package tracking number 375 is assigned, the 
shipping information related to the return transaction is stored in a package tracking 

15 database 380. Later, when the package is shipped, the parties to the transaction can 
track the progress of the package through the carrier system using the package 
tracking number 375. In one embodiment, the online return application 150 does not 
itself assign a package tracking number 375, but communicates with another carrier 
application that assigns package tracking numbers 375 and tracks packages shipped 

20 within the carrier system. 

[00101] Using the processes described above, the online return application 150 
forwards the return service request 305 to a label generation engine 160, which 
generates an image of a return shipping label 400. In Step 1030, the online return 
application 150 returns the label image to the returns portal 700. But as shown in the 

25 preceding section, in various embodiments, the online return application 150 can 
deliver a label image or an email containing a label delivery link to any specified 
location. 

[00102] In a preferred embodiment, another function of the returns portal 700 is to 
use known processes to conform, translate and reformat the label image to a standard 4 
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inch by 6 inch return shipping label 400. In Step 1040, the return portal 700 delivers 
the return shipping label 400. Fig. 12 uses dashed lines to show that the return shipping 
label 400 can be delivered either to the merchant or directly to the customer. In 
addition, other methods of providing a shipping label to a customer are described above 
5 and are equally applicable to this embodiment of the invention. 

[00103] In Step 1050, the customer receives the return shipping label 400 on a 
browser, prints and affixes the shipping label to a package and delivers the package to a 
drop-off location used by the carrier. In Step 1060, the carrier picks up the package 
from the drop-off facility and delivers the package to the consignee address, which, in a 

10 preferred embodiment, is the destination dictated by the merchant business rules. 

[00104] A benefit of the foregoing process is the streamlined access to the carrier 
online return application. Instead of requiring that the merchant integrate and/or change 
its internal systems to meet the requirements of the return system, the merchant can 
simply link to the returns portal 700 and leverage its existing interface to the carrier 

15 systems. In a preferred embodiment, the merchant need only provide a set of business 
rules and a desired look-and-feel in order to use the portal to the carrier online return 
system. 

[00105] Fig. 13 is another block diagram that lists the steps performed by a returns 
portal 700 in accordance with an embodiment of the present invention. In Step 1 100, 

20 the returns portal 700 receives data about a returns transaction. In one embodiment, a 
merchant website provides the returns data. In an alternative embodiment, the 
merchant website merely links the customer 120 to the returns portal 700, which is 
configured to prompt the customer 120 for the information necessary to authorize and 
ship the good to be returned. In still another embodiment, the customer 120 provides, 

25 or confirms, the customer's shipping information, while other necessary shipping 
and/or returns information, such as the product weight and shipping service level is 
supplied by the merchant. 

[00106] In Step 1110, the returns portal 700 applies the merchant business rules to 
the return transaction, In a preferred embodiment, the merchant business rules 
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determine whether the return is authorized and, if authorized, determines the 
appropriate consignee destination for the return. Alternatively, the merchant may have 
pre-approved the customer's return request and included an RMA number and a 
consignee destination address in the returns data sent to the portal 700. Thus, in the 
5 alternative embodiment, the application of some or all of the merchant business rules is 
handled by the merchant system rather than the returns portal 700. 
[00107] Once the customer's return request is approved and the destination of the 
good to be returned has been determined, the process proceeds to Step 1 120 where the 
returns portal 700 assembles a return service request 305 from the returns data received 
10 from the merchant and/or the customer 120. In a preferred embodiment, the return 
service request 305 is formatted as an XML document and therefore the returns portal 
700 may include any one of the many XML parser applications that are known in the 
art. 

[00108] In Step 1130, the returns portal 700 establishes communication with the 
15 online return application 150 and transmits the XML return service request 305 for 
processing. Using the processes described in the preceding sections, the online return 
application 150 in combination with the label generation application 160 processes the 
return service request 305 and produces a return service label 400. In Step 1140, the 
online return application 150 transmits the shipping label image back to the returns 
20 portal 700. 

[00109] In Step 1150, the returns portal 700 uses known processing techniques to 
reformat the label into an image that will appear as a 4 inch by 6 inch label on a 
computer browser. In a preferred embodiment, a label image printed via a web browser 
consists of an HTML file for formatting and a GIF file of the actual label image. 
25 [00110] In Step 1160, the returns portal 700 updates one or more returns portal 
transaction databases 710, which keeps a record of the return transactions processed by 
the portal 700 and the return shipping labels 400 generated. One of ordinary skill in the 
art will readily recognize that some or all of the portal transaction databases may be 
updated at various other points in the process. In a preferred embodiment, these portal 
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transaction databases 710 provide data for a variety of reports to track, for example, the 
number of transactions processed for a given merchant, the types of goods and/or the 
stock keeping units for the goods that are returned, the reasons for the return, the 
number of return requests that approved and the number refused, the number of return 
5 shipping labels generated, the package tracking numbers assigned to the return shipping 
labels generated, and the shipping charges incurred by the merchant. These examples 
are not intended to be exhaustive and one of ordinary skill in the art will readily 
recognize that a number of other reporting features related to the returns transactions 
may be generated using the returns portal transaction databases 710. 

1 0 [001 11] In Step 1 1 70, the returns portal 700 delivers the image of the return shipping 
label 400 to the intended recipient. As indicated in the previous sections, the method of 
delivery for a return shipping label 400 can take many forms via electronic and manual 
means, and the label can be delivered to a variety of recipients, the merchant, the 
customer or a third-party vendor or supplier. Moreover, the return shipping label 400 

15 can be delivered electronically as a graphic image, as an email with an embedded label 
delivery link 625 or can be delivered manually as part of a home pick-up service. One 
of ordinary skill will readily recognize that any of the processes described in the 
previous sections for providing the customer with a return shipping label 400 can be 
incorporated into an embodiment that uses the returns portal interface. 

20 [001 12] In a preferred embodiment, the online return application 150 or other carrier 
backend systems handles the billing functionality of the returns process. In one 
embodiment, the return service request 305 includes a carrier shipper or carrier account 
number that is unique to the merchant. As part of the returns processing, the online 
return application 150 validates the account number of the merchant and charges the 

25 account when the return shipping label 400 is produced. But in an alternative 
embodiment, the merchant account is not charged at the time the shipping label is 
generated and instead is charged when the customer actually uses the shipping label to 
return the good. One of ordinary skill in the art will readily recognize that the returns 
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portal also can be configured to contact the carrier billing system and that the account 
number of the merchant can be part of the reporting functionality. 
[00113] The electronic return system 10, which comprises an ordered listing of 
selectable services can be embodied in any computer-readable medium for use by or 
5 in connection with an instruction execution system, apparatus, or device, such as a 
computer-based system, processor-containing system, or other system that can fetch 
the instructions from the instruction execution system, apparatus, or device and 
execute the instructions. In the context of this document, a "computer-readable 
medium" can be any means that can contain, store, communicate, propagate, or 

10 transport the program for use by or in connection with the instruction execution 
system, apparatus, or device. The computer readable medium can be, for example 
but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or 
semiconductor system, apparatus, device, or propagation medium. More specific 
examples (a non-exhaustive list) of the computer-readable medium would include 

15 the following: an electrical connection (electronic) having one or more wires, a 
portable computer diskette (magnetic), a random access memory (RAM) (magnetic), 
a read-only memory (ROM) (magnetic), an erasable programmable read-only 
memory (EPROM or Flash memory) (magnetic), an optical fiber (optical), and a 
portable compact disc read-only memory (CDROM) (optical). Note that the 

20 computer-readable medium could even be paper or another suitable medium upon 
which the program is printed, as the program can be electronically captured, via for 
instance optical scanning of the paper or other medium, then compiled, interpreted or 
otherwise processed in a suitable manner if necessary, and then stored in a computer 
memory. 

25 [00114] Further, any process descriptions or blocks in flow charts should be 
understood as representing modules, segments, or portions of code which include 
one or more executable instructions for implementing specific logical functions or 
steps in the process, and alternate implementations are included within the scope of 
the preferred embodiment of the present invention in which functions may be 
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executed out of order from that shown or discussed, including substantially 
concurrently or in reverse order, depending on the functionality involved, as would 
be understood by those reasonably skilled in the art of the present invention. 
[00115] It should be emphasized that the above-described embodiments of the 
5 present invention, particularly any "preferred embodiments" are merely possible 
examples of the implementations, merely set forth for a clear understanding of the 
principles of the invention. Any variations and modifications may be made to the 
above-described embodiments of the invention without departing substantially from the 
spirit of the principles of the invention. All such modifications and variations are 
10 intended to be included herein within the scope of the disclosure and present invention 
and protected by the following claims. 

[00116] In concluding the detailed description, it should be noted that it will be 
obvious to those skilled in the art that many variations and modifications can be 
made to the preferred embodiment without substantially departing from the 
15 principles of the present invention. Also, such variations and modifications are 
intended to be included herein within the scope of the present invention as set forth 
in the appended claims. Further, in the claims hereafter, the structures, materials, 
acts and equivalents of all means or step-plus function elements are intended to 
include any structure, materials or acts for performing their cited functions. 
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